Skip to content

Localize Core Messages#2664

Draft
GLWine wants to merge 7 commits into
EDCD:developfrom
GLWine:Localize-Core-Message
Draft

Localize Core Messages#2664
GLWine wants to merge 7 commits into
EDCD:developfrom
GLWine:Localize-Core-Message

Conversation

@GLWine
Copy link
Copy Markdown
Contributor

@GLWine GLWine commented May 14, 2026

Description:

This PR implements localization for core application messages in EDMarketConnector.py, enabling translation of critical user-facing strings such as error popups, notifications, and startup warnings. The changes standardize message formatting and consolidate i18n handling across the application.

This work is a parallel integration to PR #2617, which localized the authentication success message. Together, these changes expand localization coverage to additional core UI elements while maintaining consistency with the established patterns.

Key Changes:

  • Import Optimization: Moved l10n import earlier and removed duplicate imports to ensure translations are available throughout the file.
  • String Localization: Replaced hard-coded strings in popups, notifications, and dialogs with tr.tl() calls for proper translation support.
  • Newline Standardization: Introduced {LF}{CR} placeholders in localization strings to handle line breaks consistently, replacing manual replace('\\n','\n').replace('\\r','\r') post-processing.
  • New Localization Entries: Added translations for startup messages including journal lock warnings and duplicate process detection.
  • Updated Templates: Modified en.template to include new entries and standardize existing ones with newline placeholders.

Files Modified:

  • EDMarketConnector.py: 58 lines changed (+34/-24) - Added translation calls and removed manual formatting.
  • en.template: 18 lines changed (+12/-6) - Added new strings and updated formatting.

Benefits:

  • Improves user experience for non-English speakers by localizing core error and status messages.
  • Centralizes message handling, making future translations easier.
  • Ensures consistent formatting across all localized messages.

This PR targets the develop branch and maintains backward compatibility while enhancing internationalization support. All changes are based on the existing l10n infrastructure and follow the project's translation patterns established in PR #2617.

Attention: @Rixxan

GLWine and others added 3 commits May 14, 2026 02:05
Import l10n translations earlier and replace hard-coded popup/notification strings with tr.tl(...) calls using CR/LF placeholders. Standardize message formatting across journal-lock, process-already-running, update notifications, provider reset, plugin errors and critical error dialogs, remove manual \"replace('\\n','\n').replace('\\r','\r')\" post-processing and the duplicate l10n import. This consolidates i18n handling and normalizes linebreak formatting for localized messages.
Update L10n/en.template to replace literal CRLF sequences in several localized popup strings with {LF}{CR} placeholders for consistent newline handling. Also add two new localization entries for journal-lock and duplicate-process startup warnings and adjust plugin, provider-reset, and update-track messages to use the new placeholders.
@Rixxan
Copy link
Copy Markdown
Contributor

Rixxan commented May 29, 2026

I'm wary about the newline conversion to {LF}{CR}{LF}{CR}. How will this impact bundled languages? Will updates need to be made to every language or risk crashes? (While in theory I'm not against standardizing newlines, it's one of those "the way it's always been" things that I'm worried might introduce unintended consequences.

Rixxan and others added 4 commits May 31, 2026 15:52
Wrap several user-facing messages and labels in the translation helper (tr.tl) and add LANG comments for clarity. Replace ad-hoc CR/LF placeholders with a single EOL replacement ("\r\n") for consistent end-of-line handling across popups and dialogs. Changes affect update-track prompts, killswitch popup text and title, provider-reset notifications, critical error details, and plugin-related warning popups, and make the OK button label translatable.
Normalize localization messages by replacing legacy {LF}{CR} sequences with the {EOL} token and updating comment metadata/line references across EDMarketConnector entries (critical error details, plugin warnings, broken plugin text, provider reset messages, Beta->Stable notice, etc.). Clarify OK button comment to include the killswitch dismiss button. Add new localization keys for the killswitch popup: body text, title "EDMC Features have been disabled", and the "Version: {VERSION}" label.
Unify CR placeholder replacement in l10n module

Remove .format(CR="\n") calls from EDMarketConnector.py and companion.py
to centralize line break handling in the localization module. The l10n.py
module already replaces {CR} placeholders during translation parsing.

This simplifies the codebase by eliminating redundant format() calls
and ensuring consistent behavior across all localized strings.
@GLWine
Copy link
Copy Markdown
Contributor Author

GLWine commented Jun 1, 2026

Hey @Rixxan, thanks for the feedback! Your concern was valid, here's the full picture:

How placeholders are handled

  • I removed the inline .format() calls only for {CR}: {CR} is already handled by l10n.py
  • {EOL} is handled with .format() where it is used
    • We could make l10n.py always handle the substitution, but for now it's done inline where {EOL} appears

Behavior with existing translations

  • Translations that are not yet updated fall back to the untranslated string
  • No crashes, just fallback until the translation is refreshed

Impact on Crowdin

  • Strings that previously used \n or \r\n now use {CR} and {EOL}
  • Crowdin sees them as new strings and they need to be re-synced
  • The translations already exist, they just need to be updated with the new placeholder

Conclusion

  • The impact is limited to the affected strings
  • Fallback is in place until translations are updated on Crowdin

TODO (next step)

In a follow-up (either in this PR or a new one), we can move the {EOL} substitution into l10n.py itself, just like {CR}. This would be done in two places:

  1. contents() — when loading translations from .strings files:

    to_set = match.group(2).replace(r'\"', '"').replace('{CR}', '\n').replace('{EOL}', '\r\n')
  2. translate() — in the fallback path when the string is missing:

    return self.translations[None].get(x) or str(x).replace(r'\"', '"').replace('{CR}', '\n').replace('{EOL}', '\r\n')

This would let us remove all inline .format() calls for {EOL} and centralize the logic in one place, making the codebase cleaner and more consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants